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All  We  Need  to  Know  About 
Software  Project  Management, 

We  Can  Learn  From  Watching  Star  Trek 


David  R.  Webb 

309  Software  Maintenance  Group,  Mill  Air  Force  Base 

Are  you  Kirk,  Spock,  Sulu,  Chekov,  Uhura,  or  Scotty?  If  you  are  part  of  a  modern-day  software  engineering  team,  chances 
are  you  fit  one  of  these  roles.  As  we  have  read  about  Star  Trek^  influence  on  technology,  sit  hack  for  a  warp  drive  look  at 
how  a  software  engineering  team's  structure  mimics  that  of  the  Star  Trek  bridge  crew. 


A  few  months  ago,  I  watched  a  cable  TV 
show  which  asserted  that  a  Star  Trek 
actor  had  changed  the  world.  While  the  idea 
that  William  Shatner  had  single-handedly 
brought  about  the  21st  century  as  we  know 
it  was  funny,  the  information  presented  was 
pretty  convincing  that  the  science  fiction 
show  had  a  major  impact  on  modern  tech¬ 
nology  Just  call  your  bank’s  voice-recogni¬ 
tion  computer  using  your  flip-phone  and 
. . .  well,  you  get  the  picture.  And  it  does  not 
end  with  the  original  series;  those  reconfig- 
urable,  flat-panel  touch  screens  that  Geordi 
and  Data  sit  in  front  of  in  The  Next 
Generation  can  now  be  found  in  just  about 
every  fast  food  restaurant! 

As  I  marveled  at  the  effects  a  televi¬ 
sion  series  had  had  on  our  modern  lives,  I 
suddenly  realized  that  most  of  the  current 
software  generation  had  grown  up  with 
Star  Trek.  I  began  wondering  what  effect 
this  had  on  our  approaches  to  software 
development  and  management.  What  I 
discovered  I  have  termed  The  Gene 
Toddenberry  Effect.  Everything  we  do  in 
software  project  management  originated 
with  Star  Trek.  I  have  developed  a  list  of 
lessons  learned  from  Star  Trek  that  I  regu¬ 
larly  employ. 

The  Bridge  Crew 

One  surprising  example  of  how  Star  Trek 
has  affected  software  project  management 
is  how  the  composition  of  the  bridge  crew 
on  the  starship  Enterprise  reflects  that  of 
current  software  teams.  In  the  original 


series,  most  of  the  stories  centered  around 
the  bridge  crew:  Kirk,  Spock,  Sulu, 
Chekov,  Uhura,  Scotty  (you  know  the 
names).  Kirk  was  the  ultimate  leader  and 
decision-maker,  Spock  was  second-in- 
command  and  science  officer,  and  all  the 
others  had  specific  job  titles  as  well. 

Modern  industry  has  pretty  much  bor¬ 
rowed  this  structure  for  software  engi¬ 
neering  teams.  Every  project  has  a  project 
manager  (PM),  a  technical  expert  who  acts 
as  backup  PM,  a  chief  engineer,  a  com¬ 
munications  officer  (configuration  manag¬ 
er),  and  so  forth.  The  PM  calls  the  shots, 
much  like  the  captain  (Kirk),  and  everyone 
else  performs  their  particular  jobs  and  reg¬ 
ularly  reports  back  to  him.  When  the  team 
has  issues,  it  gathers  in  a  conference  room 
and  projects  everything  on  a  flat  panel 
monitor  for  all  to  review.  The  team  makes 
a  group  decision,  guided  and  ratified  by 
Kirk.  Watch  those  conference  meetings  in 
the  original  series  and  see  if  you  get  goose 
pimples  at  how  similar  they  are  to  the 
meetings  you  go  to  each  week. 

Perhaps  most  surprising  is  the  similari¬ 
ty  between  the  bridge  crew  concept  in  con¬ 
junction  with  the  Software  Engineering 
Institute’s  (SEI)  Team  Software  Process^^ 
(TspsM^,  The  TSP  is  SETs  how-to  guide  for 
implementing  high-maturity  software  engi¬ 
neering  teams.  In  the  TSP,  each  member  of 
the  team  is  given  one  of  eight  management 
roles.  As  I  began  looking  at  them,  I  was 
amazed  at  how  closely  they  matched  the 


bridge  crew  concept  (see  Table  1). 

What  is  even  more  interesting  is  that 
many  TSP  teams  actually  do  double  up  on 
roles  as  shown  in  Table  1.  If  they  do  not 
have  eight  people  to  perform  the  different 
roles,  people  take  on  more  than  one. 

But  wait;  it  gets  even  better. 

Once  we  move  to  The  Next  Generation 
series,  we  find  a  whole  new  bridge  crew 
with  expanded  roles.  In  this  case,  Picard, 
the  captain,  is  no  longer  the  PM,  but  has 
risen  to  the  rank  of  senior  management  (as 
described  in  SETs  Capability  Maturity 
Model  Integration  1.1).  We  can  see  from 
Table  2  that  the  team  concept  has  matured 
aboard  the  newer  Enterprise  and  that  our 
more  modern  approaches  to  the  software 
team  concept  have  mimicked  this  structure. 

We  could  go  even  further  and  examine 
the  newer  agile  development  methodolo¬ 
gies  only  to  discover  that  as  the  Star  Trek 
series  matured,  so  did  their  concepts  of 
teams  and  agility.  Captain  Janeway’s 
Federation/Maquis  team  aboard  Voyager, 
for  example,  is  the  epitome  of  an  agile 
team.  In  any  case,  whether  or  not  it  was 
done  intentionally,  it  seems  that  modern 
software  teams  are  indeed  modeled  after 
the  Star  Trek  bridge  crews.  Some  of  the 
agile  methods  even  measure  a  project  veloc¬ 
ity.  A  coincidence?  Well,  maybe. 

Lessons  Learned 

So,  with  the  obvious  links  between  the  Star 
Trek  universe  and  the  way  we  manage  soft¬ 
ware  projects,  what  else  we  can  learn  from 
Star  Trek  that  can  actually  help  us  in  our 
day-to-day  management  of  software  pro¬ 
jects?  The  following  are  the  10  project  man¬ 
agement  tips  I  use  most  often: 

10.  When  push  comes  to  shove,  it’s  always 
a  computer  geek  who  comes  to  the 
rescue!  (Watch  just  about  every  Star 
Trek:  The  Next  Generation  episode  with 
Wesley  Crusher.) 

9.  Your  greatest  challenges  can  be  the 
ones  you  thought  you  got  rid  of  200 
years  ago.  (Remember  Kahn  [Ricardo 
Montalban]  from  the  original  episode 


Table  1 :  TSP  Roles  vs  Enterprise  Bridge  Grew 


TSPSM  Roles 

Bridge  Crew  Role 

Bridge  Crew  Member 

Team  Leader 

Captain 

Kirk 

Customer  Interface  Manager 

Communications  Officer 

Uhura 

Design  Manager 

Science  Officer 

Spock 

Implementation  Manager 

Chief  Engineer 

Scotty 

Planning  Manager 

Navigation  Officer 

Sulu 

Process  Manager 

Operations  Officer 

Chekov 

Quality  Manager 

Medical  Officer 

Bones 

Support  Manager 

Science  Officer 

Spock 

Test  Manager 

Chief  Engineer 

Scotty 
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TSPSM  Roles 

Bridge  Crew  Role 

Bridge  Crew  Member 

Senior  Management 

Captain 

Picard 

Team  Leader 

First  Officer 

Riker 

Customer  Interface  Manager 

Security  Officer 

Worf 

Design  Manager 

Science  Officer 

Data 

Implementation  Manager 

Chief  Engineer 

Geordi 

Planning  Manager 

Navigation  Officer 

Wesley 

Process  Manager 

Operations  Officer 

Data 

Quality  Manager 

Medical  Officer 

Crusher 

Support  Manager 

Ship’s  Councilor 

Troi 

Test  Manager 

Chief  Engineer 

Geordi 

Table  2:  TSP  Poles  vs  The  Next  Generation  Enterprise  Bridge  Crew 


Space  Seed  and  the  movie  Star  Trek  II? 
Remember  Y2K?) 

8.  If  everyone  on  your  project  is  too 
happy,  you  probably  are  not  accom¬ 
plishing  anything.  (Yes,  it’s  the  hippie 
episode  about  the  spores,  called  This 
Side  of  Paradise.  For  those  who  are  not 
ardent  fans,  trust  us  on  this  one.) 

7.  You  cannot  change  the  laws  of 
physics,  but  you  can  bend  them.  (This 
is  a  line  made  famous  by  Scotty  in  the 
original  series  episode  entitled  The 
Naked  Time.) 

6.  There  is  no  such  thing  as  a  no-win  sce¬ 
nario,  especially  if  you  change  the  con¬ 
ditions  of  the  test.  (This  is  Kirk’s  phi¬ 
losophy  and  fits  pretty  well  into  his 
profile  above!  Watch  Star  Trek  II  —  The 
Wrath  of  Kahn  for  how  this  worked  for 
him  ...  or  did  not.) 

5.  Every  successful  project  manager  has 
both  a  good  side  and  bad  side  and 
knows  how  to  balance  them.  (Let’s  just 
hope  you  do  not  beat  yourself  up  the 
way  Kirk  did  in  The  Enemy  Within  —  liter¬ 
ally.  In  that  episode,  Kirk  had  an  evil  twin 
created  by  a  transporter  malfunction.) 

4.  Don’t  feed  the  Tribbles  or  they  will 
overrun  you!  (Substitute  your  own  set 
of  problems  for  Tribbles  as  seen  in  The 
Trouble  with  Tribbles.  If  you  do  not 
know  what  a  Tribble  is,  why  are  you 
reading  this  article?) 

3.  If  you  do  not  apply  a  lot  of  power  to 
break  away  from  your  routine,  you  are 
doomed  to  repeat  the  same  mistakes 
over  and  over  again  for  eternity.  (fThe 
Causality  Eoop  from  The  Next  Generation 
—  great  episode!  Go  rent  it!) 

2.  Some  people  can  be  very  afraid  of 
change.  (Let  us  just  hope  it  doesn’t 
lead  to  the  shedding  of  blood,  red  or 
pink  as  it  did  in  the  movie  Star  Trek  WI 
—  The  Undiscovered  Country) 


1.  Always  multiply  your  estimates  by  a 
factor  of  four  so  that  you  will  be 
known  as  a  miracle  worker.  (This  comes 
from  the  movie  Star  Trek  III  —  The 
Search  for  Spock,  and  we  have  no  com¬ 
ment  as  to  why  this  is  number  one  or 
how  we  implement  it;  especially  if  any 
of  our  customers  are  reading  this!) 
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Webb  is  a  Software  Engineering  Institute- 
authorized  instructor  of  the  Personal 
Software  Process^^,  a  Team  Software 
Process  launch  coach,  and  has  worked  as 


Conclusion 

While  this  article  is  a  bit  tongue-in-cheek, 
it’s  amazing  how  closely  our  software  engi¬ 
neering  practices  mirror  Star  Trek.  So  live 
long,  prosper,  and  remember  to  thank  (or 
maybe  curse)  great  bird  of  the  galaxy  next 
time  you  put  together  those  PowerPoint 
slides  for  your  management  review! ♦ 


an  Air  Force  flight  director.  Software 
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